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Foreword 



This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3 GPP and ETSI identities can be found under 
http ://webapp . etsi .org/key/query f orm. asp . 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



ETSI 



3GPP TS 24.642 version 8.0.1 Release 8 6 ETSI TS 1 24 642 V8.0.1 (2009-01 ) 



Scope 



The present document specifies the stage three Protocol Description of the Completion of Communications to Busy 
Subscriber (CCBS) service and the Completion of Communication on no Reply (CCNR) service, based on stage one 
and two of the ISDN supplementary services. It provides the protocol details in the IP Multimedia (IM) Core Network 
(CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). 

The Completion of Communications to Busy Subscriber CCBS service enables user A, encountering a busy 
destination B, to have the communication completed without having to make a new communication attempt when the 
destination B becomes not busy. 

The Completion of Communications on No Reply CCNR supplementary service enables user A, encountering a 
destination B which does not answer the communication (No Reply), to have the communication completed without 
having to make a new communication attempt when the destination becomes not busy after having initiated an activity. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the CCBS and CCNR supplementary services. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] and the following 
terms and definitions apply. 

busy: See ITU-T Recommendation 1.221 [x], subclause 2.1.5. 

call information retention: A procedure of network A to store the call information of a specific call so that it can be 
used for that call. 

caller: The user who originated the call and to whom the CCBS service is provided. 

callee: The user which is identified as destination B. 

CC: Completion of Communication 

CC busy: Any one of the following conditions will cause a CCBS busy condition: 

maximum number of calls reached at user A (see ITU-T Recommendation 1.221 [x], subclause 2.1.3, item 2)); 

- no resources (bandwidth) available at user A; 

- CC recall pending on user A. 
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CCBS/CCNR call: A call generated by the network connecting the caller to the callee, resulting from the callers' 
acceptance of a CCBS/CCNR recall. 

CCBS/CCNR recall: An indication informing the caller that the network is ready to initiate a CCBS/CCNR call to the 
callee and that the network is awaiting a response to this indication. 

CCBS/CCNR request: An instance of an activation of the CCBS/CCNR service which is held in a queue pending the 
correct conditions for the CCBS/CCNR service to be completed. 

Suspended CCBS/CCNR request: A CCBS/CCNR request which cannot be served even if the callee is in the 
appropriate state because the caller is busy. 

CCBS/CCNR request retention: If an attempt to establish a CCBS/CCNR call fails because the destination is busy 
again, then the network provider option "CC request retention" defines whether the CCBS supplementary service is 
continued or not, i.e. if the "CC request retention" is supported, the original CCBS/CCNR request retains its position in 
the queue B, and monitoring of user B shall continue. Otherwise the CCBS/CCNR request is revocated. 

CC service duration timer: A maximum time the CC service will remain activated for the caller within the network. 

destination B: The entity addressed in the original call. 

long-term denial: The network cannot accept user A's request to activate the CC service and a later attempt to activate 
the CC service for the same destination B will also be rejected. 

queue A: A buffer at the originating side for the control of CCBS/CCNR requests associated with the caller. 

queue B: A buffer at the terminating side for the control of CCBS/CCNR requests associated with destination B. 

retain option: The retain option, if supported in both the originating and destination network, will maintain the 
CCBS/CCNR request in the destination B queue, if a CCBS/CCNR call has failed due to destination busy condition. 

short-term denial: The network temporarily cannot accept user A's request to activate the CC service. A later attempt 
to activate the CC service for the same destination B may succeed. 

UE-A: The caller's UE. 

UE-B: The callee' sUE. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AOC Advice Of Charge 

AS Application Server 

CB Communication Barring 

CC Completion of Communications 

CCBS Completion of Communication to Busy Subscriber 

CCNR Completion of Communications on No Reply 

CD Communication Deflection 

CDIV Call Diversion 

CFB Communication Forwarding Busy 

CFNL Communication Forwarding on No Logged-in 

CFU Communication Forwarding Unconditional 

CN Core Network 

CNR Completion of communication on No Reply 

CONE CONFerence calHng 

CS Circuit Switched 

CW Communication Waiting 

ECT Explicit Communication Transfer 

HOLD Communication HOLD 

IFC Initial Filter Criteria 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

IP Internet Protocol 
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ISDN 

MCID 

MIME 

OIP 

OIR 

PLMN 

PSTN 

SIP 

TIP 

TIR 

UE 



Integrated Service Data Network 
Malicious Communication IDentification 
Multipurpose Internet Mail Extensions 
Originating Identification Presentation 
Originating Identification Restriction 
Public Land Mobile Network 
Public Switch Telephone Network 
Session Initiation Protocol 
Terminating Identification Presentation 
Terminating Identification Restriction 
User Equipment 



Completion of Communications to Busy Subscriber 
(CCBS) / Completion of Communication on No Reply 
(CCNR) 



4.1 



Introduction 



The CCBS and CCNR services enables a user, encountering a destination that is busy or does not answer, to have the 
communication completed at a later point in time without the user having to manually initiate a new communication 
attempt. 

4.2 Description 
4.2.1 General description 

The CCBS service enables user A, encountering a busy destination B, to have the communication completed without 
the user having to manually initiate a new communication attempt when the destination B becomes not busy. 

When user A requests the CCBS supplementary service, the network will monitor for destination B becoming free 
again. 

When destination B becomes free again, the network will wait a short time in order to allow the resources to be re-used 
for originating a communication. If the resources are not re-used by destination B within this time, the network will 
automatically recall user A. 

When user A accepts the CCBS recall, the network will automatically generate a CCBS call to destination B. 

The CCNR supplementary service enables user A, encountering a destination B which does not answer the 
communication (No Reply), to have the communication completed without the user having to manually initiate a new 
communication attempt when the destination becomes not busy after having initiated and completed a new 
communication. 

When user A encounters a destination B which does not answer the communication (No Reply), user A can request the 
CCNR supplementary service. 

When user A requests the CCNR supplementary service, the network will monitor for destination B becoming not busy 
after having initiated and completed a new communication. 

When destination B becomes not busy after having initiated and completed a new communication, the network will wait 
a short time (as defined by the destination B idle guard timer) in order to allow the resources to be reused for originating 
a communication. If the resources are not reused by destination B within this time, the network will automatically recall 
user A. 

When user A accepts the CCNR recall, then the network will automatically generate a CCNR call to destination B. 
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The CCBS / CCNR service control is done by the appHcation servers. It is possible to modify the queue by the users 
(add entry, delete entries, delete whole queue) by usage of appropriate procedures. 

On the originating side the originating AS A manages the queue of user A and on terminating side the terminating AS B 
manages the queue of outstanding communications towards UE B. 

The originating AS keeps track of the CCBS/CCNR requests started by each user for a given period of time, and rejects 
a new request in case the provisioned limit has been overcome. 

The terminating AS keeps track of the CCB /CCNR requests directed to each user for a given period of time, and rejects 
a new request in case the provisioned limit has been overcome. 

After successful CCBS/CCNR Call setup the respective entry is deleted in both queues. Also a proper management of 
the queue in the suspend/resume scenario upon reception of the corresponding message takes place. 

4.3 Operational requirements 
4.3.1 Provision/withdrawal 

The CCBS/CCNR service is provided to the served user after prior arrangement with the service provider, or as a 
service provider option. Withdrawal of these services is made on the served user's request or for service provider 
reasons. 

4.4 Coding requirements 

No specific requirements needed. 

4.5 Signalling requirements 

4.5. 1 Activation/deactivation 

The call completion services are individually activated at provisioning or at the subscriber's request. 
The call completion services are individually deactivated at withdrawal or at the subscriber's request. 

4.5.2 Registration/erasure 

The CCBS/CCNR service requires no registration. Erasure is not applicable. 

4.5.3 Interrogation 

For the interrogation of the call-completion services the Ut interface using XC AP as enabling protocol as described in 
3GPP TS 24.623 [4] or SIP based user configuration as described in 3GPP TS 24.238 [7] in combination with 
announcement procedures according to 3GPP TS 24.628 [3] could be used use. 

4.5.4 Invocation and operation 
4.5.4.1 Actions at the originating UE 

Basic call procedures and in case of an call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3 GPP TS 24.229 [2] shall apply. 

For invoking and revoking of the call completion services, announcement procedures according to 3GPP TS 24.628 [3] 
and inband-interaction procedures should be used. 
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Editor's note: The usage of inband interaction procedures needs further studies and specification. For invoking and 
revoking of the call-completion services also out-of-band stimulus procedures according to ETSI TR 183 
057 [4] could be used. 

4.5.4.2 Actions at the originating AS 

4.5.4.2.0 General 

The originating AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] or operate as a 
routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] for the incoming INVITE request and all future 
requests and responses in the same dialog. 

4.5.4.2.1 CC Invocation 
4.5.4.2.1 .1 Normal procedures 

4.5.4.2.1 .1 .1 Detecting if CC is possible 

When in case of CCBS a 486 (Busy Here) response has been received from the terminating network, and the following 
set of conditions apply: 

- the 486 (Busy Here) response contains an Call-Info header field with a "purpose" header field parameter set to 
"call-completion"; and 

- the user A CCBS queue limit has not been exceeded; and 

- CCBS has not been activated for an identical communication (network option), determined by the stored basic 
communication information defined in subclause 4.5.4.2.1.1.2; and 

- there are no service interactions that preclude CCBS; 

then the service retention procedure as specified in subclause 4.5.4.2.1.1.2 is executed. 

When in case of CCNR a 1 80 (Ringing) response has been received from the terminating network, and the following set 
of conditions apply: 

- the 180 (Ringing) response contains an Call-Info header with a purpose parameter set to 'call-completion'; and 

- the user A CCNR queue limit has not been exceeded; and 

CCNR has not been invoked for an identical communication (network option), determined by the stored basic 
communication information defined in subclause 4.5.4.2.1.1.2; and 

- there are no service interactions that preclude CCNR, 

then the service retention procedure as specified in subclause 4.5.4.2.1.1.2 is executed. The originating AS shall remove 
the Call-Info header from the 180 (Ringing) response, forward it to UE-A and start the CC no-reply timer CCNR-T5. 

4.5.4.2.1 .1 .2 Starting of the service retention procedure 

The originating AS shall start the retention timer CC-Tl. The originating AS shall retain the following information from 
the original communication, if available: 

1) SDP offer, and 

2) Request-URI, and 

3) To header field, and 

4) From header field, and 

5) Privacy header field, and 

6) P-Asserted-ID header field. 
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4.5.4.2.1 .1 .3 CC service invocation by user A 

For the invocation of the CC service, in case of CCBS immediately after receipt of a 486 (Busy Here) response with a 
CCBS possible indication or in case of CCNR after receipt of a 180 (Ringing) response with a CCNR possible 
indication upon expiry of the No-Reply timer CCNR-T5, the originating AS shall provide an announcement that CCBS 
is possible to user A, according to 3GPP TS 24.628 [3], followed by inband-interaction procedures for the activation 
confirmation,. 

NOTE: User A can have a limited number of CC requests outstanding. This limit is a network provider option 
(with a maximum value of 5). 

4.5.4.2.1 .1 .4 Stopping of the service retention procedure 

On receiving a CC invocation confirmation from user A before the expiry of the retention timer CC-Tl, the originating 
AS shall: 

a) stop the retention timer CC-Tl ; and 

b) store the retained call information from the original basic communication. 

4.5.4.2.1 .1 .5 Sending of the CC request to the terminating AS 

The originating AS shall send a SUBSCRIBE request to the terminating AS according to RFC 3265 [6] and draft-ietf- 
bliss-call-completion [5]. The originating AS shall populate the SUBSCRIBE request as follows: 

- a Request-URI set to the URI of the terminating AS 

- in case of CCBS as received in the Call-Info header field in the 486 (Busy Here) response, including a "m" 
SIP URI parameter with a value set to "BS"; 

- in case of CCNR as received in the Call-Info header in the 180 (Ringing) response, including a "m"- SIP URI 
parameter with a value set to "NR"; 

a From header field set to the URI of UE-A from the original communication; 

- a To header field set to the URI of UE-B from the original communication; 

- a Contact header field set to the URI of the originating AS. 

The originating AS shall start the CC request timer CC-T2. 

NOTE: The difference in the URIs in the Request-URI and the To header field is to identify a particular CC 
target. 

4.5.4.2.1 .1 .6 Procedures after CC invocation confirmation from the terminating AS 

If the originating AS receives a NOTIFY request as an answer to an outstanding CC request which was described in 
subclause 4.5.4.2.1.1.5 with the cc-state parameter set to 'queued', the originating AS shall: 

a) stop the CC request timer CC-T2; 

b) start the CCB service duration timer CC-T3; 

c) store the information whether the cc- service-retention parameter has been received or not; and 

d) confirm to the caller that the invocation was successful, using announcement procedures according to 
3GPPTS 24.628 [3]. 

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A. 

4.5.4.2.1 .2 Exceptional procedures 

If the originating AS receives a NOTIFY request as an answer to an outstanding CC request which was described in 
subclause 4.5.2.2.1.1.5 with: 
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- the Subscription-State header field set to "terminated"; and 

- the "reason" Subscription-State header field parameter set to "rejected"; 
then the originating AS shall: 

a) stop the CC request timer CC-T2; and 

b) confirm to the caller that the invocation was not successful, using announcement procedures according to 
3GPPTS 24.628 [3]. 

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A. 

4.5.4.2.2 CC Revocation 

4.5.4.2.1 Normal procedures 

4.5.4.2.2.1 .1 Generating a revocation request 

For revoking the CC service, the originating AS shall send a SUBSCRIBE request to the terminating AS according to 
RFC 3265 [6] and draft-ietf-bliss-call-completion [5] . The originating AS shall populate the SUBSCRIBE request as 
follows: 

- a Request-URI set to the URI of the terminating AS 

- in case of CCBS as received in the Call-Info header field in the 486 (Busy Here) response, including a "m" 
SIP URI parameter with a value set to "BS"; 

in case of CCNR as received in the Call-Info header in the 180 (Ringing) response, including a "m"- SIP URI 
parameter with a value set to "NR"; 

- a the From header field set to the URI of UE-A from the original communication; 
a To header field set to the URI of UE-B from the original communication; 

- a Contact header field set to the URI of the originating AS. 

- an Expires header field set to zero; 

NOTE: The difference in the URIs in the Request-URI and the To header field is to identify a particular CC 
target. 

4.5.4.2.2.1 .2 Revocation requested by the user 

If the originating AS receives a revocation request by the user, the originating AS shall 

- construct a SUBSCRIBE request according to subclause 4.5.4.2.2.1.1; and 

- send the SUBSCRIBE request to the terminating AS; and 

inform user A of the result of the revocation by using announcement procedures and inband-interaction 
procedures according to 3GPP TS 24.628 [3]. 

4.5.4.2.2.1 .3 Revocation caused by timer expiry 

If the service-duration timer CC-T3 expires, the originating AS shall: 

- construct a SUBSCRIBE request according to subclause 4.5.4.2.2.1.1; and 

- send the SUBSCRIBE request to the terminating AS. 

Editor's note: Is there a need to inform the terminating AS about the cancellation reason (service duration timer, 
recall timer)?. 
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4.5.4.2.2.2 Exceptional procedures 

Not applicable 

4.5.4.2.3 CC Operation 

4.5.4.2.3.1 Normal procedures 

On receipt of a CC recall notification as described in subclause 4.5.4.3.4.1.2, and if user A is neither busy nor CC busy, 

the originating AS shall initiate the CC recall to user A by sending a REFER request to UE-A according to 

3GPP TS 24.229 [2], and shall start the recall timer CC-T4. The originating AS shall populate the REFER request as 

follows: 

- a Request-URI set to the URI of UE-A from the original communication, including a "m" SIP URI parameter 
with a value set to "BS"; and 

- a Refer-to header set to the URI of UE-B. 

If there are multiple outstanding CC requests at the originating AS, then the correct target for the CC recall is identified 
using standard SIP dialog identification procedures. 

In the case UE-A does not support the REFER method extension, the special REFER request handling procedures 
according to 3GPP TS 24.628 [3] should be used. As a network option, e.g. in the case the originating AS has 
knowledge that UE-A does not support the REFER method extension, the originating AS may start the 3rd party call 
control procedures according to 3GPP TS 24.628 [3] without waiting for an 3xx - 6xx response. In this case, the 
originating AS shall send an INVITE request with a Request-URI set to the URI of UE-A from the original 
communication, including a "m" SIP URI parameter with a value set to "BS". 

If user A accepts the recall before the CC recall timer expires (a NOTIFY request with a body containing SIP/2.0 100 
Trying or a 200 OK to the 3pcc INVITE request according to the special REFER request handling procedures according 
to 3GPP TS 24.628 [3] is received), the originating AS shall stop timer CC-T4 and initiate the CC call to destination B 
by sending an INVITE request, in accordance with draft-ietf-bliss-call-completion [5]. The originating AS shall 
populate the INVITE request as follows. 

- a Request-URI set to the URI of UE-B from the original communication, including a "m" SIP URI parameter 

- set to "BS" in case of CCBS; or 

- set to "NR" in case of CCNR; 

- a From header field set to the URI of UE-A from the original communication; 
a To header field set to the URI of UE-B from the original communication. 

4.5.4.2.3.2 Exceptional procedures 

4.5.4.2.3.2.1 Non-acceptance of CC recall 
See subclause 4.5.4.2.2.1.3. 

4.5.4.2.3.2.2 User A is found busy or CC busy 

If the caller is found to be busy or CC busy, when a CC recall notification as described in subclause 4.5.4.3.4.1.2 has 
been received, then the originating AS shall suspend the CC request until the caller becomes not busy or not CC busy 
again. The originating AS shall send a PUBLISH request to the terminating AS according to draft-ietf-bliss-call- 
completion [5]. The originating AS shall populate the PUBLISH request as follows: 

- a Request-URI set to the URI of the terminating AS 

- in case of CCBS as received in the Call-Info header field in the 486 (Busy Here) response, including a "m" 
SIP URI parameter with a value set to "BS"; 

in case of CCNR as received in the Call-Info header in the 180 (Ringing) response, including a "m"- SIP URI 
parameter with a value set to "NR"; 
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- a To header field set to the URI of UE-B from the original communication; 

- a body set to a PIDF informing about the basic state 'closed' for the caller's identity as presentity. 

NOTE: The difference in the URIs in the Request-URI and the To header field is to identify a particular CC 
target. 

When the caller is no longer busy or CC busy, then the originating AS shall resume the CC request. The originating AS 
shall send a PUBLISH request to the terminating AS according to draft-ietf-bliss-call-completion [5]. The originating 
AS shall populate the PUBLISH request as follows: 

- a Request-URI set to the URI of the terminating AS 

- in case of CCBS as received in the Call-Info header field in the 486 (Busy Here) response, including a "m" 
SIP URI parameter with a value set to 'BS'; 

in case of CCNR as received in the Call-Info header in the 180 (Ringing) response, including a "m"- SIP URI 
parameter with a value set to "NR"; 

a To header field shall contain the URI of UE-B from the original communication; 

- a body set to a PIDF informing about the basic state 'open' for the caller's identity as presentity. 

NOTE: The difference in the URIs in the Request-URI and the To header field is to identify a particular CC 
target. 

In case of the originating AS had sent several suspension requests to different terminating ASs and the caller becomes 
neither busy nor CC busy, the originating AS shall resume each suspended request. 

4.5.4.2.3.2.3 The caller makes another call to the same destination B 

If the caller initiates another communication to the same destination B and activates the same CC service (CCBS or 
CCNR) again, then: 

- if the two communications are identical, then the following network provider option exists: 

1) the originating AS shall retain the original request with the current request being discarded and inform the 
caller that the request has not been accepted because a CC request had already been stored against the 
requested destination B; or 

2) the originating AS shall treat this as a new CC request; and 

- if the two calls are not identical, then the originating AS shall treat this as a new CC request. In order to decide 
that the two calls are identical, the originating AS shall only compare the basic communication information, i.e. 
the SDP offer, the destination selection information, and calling user identity (if any). 

Editor's note: It is FES which information shall be used to identify identical communications. 

4.5.4.2.3.2.4 CC call failure 

If the CC call fails, the originating AS shall inform the caller as for the basic communication procedures. 

If CC is possible (a received 180 (Ringing) or 486 (Busy Here)) response contains a Call-Info header field with a 
purpose parameter set to "call-completion"), two possibilities exist: 

- if the retain option is supported across the networks (the originating AS has received a cc- service-retention 
parameter in the NOTIFY request described in subclause 4.5.4.3.2.1), the originating AS shall keep the 
transaction resources and shall not restart the service duration timer CC-T3. If the caller attempts to activate CC 
again, the originating AS shall treat this as described in subclause 4.5.4.2.3.2.3. 

- if the retain option is not supported across the networks, the originating AS shall release the transaction 
resources. The originating AS shall deactivate the CC request and shall inform the caller accordingly. 

If CC is not possible (a received 180 (Ringing) or 486 (Busy Here)) response does not contain a Call-Info header field 
with a purpose parameter set to 'call-completion'), the originating AS shall deactivate the CC request according to the 
procedures described in subclause 4.5.4.2.2 and shall inform the caller accordingly. 
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4.5.4.3 Actions at the ternninating AS 

4.5.4.3.0 General 

The terminating AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] or operate as a 
routing B2BUA as specified in clause 5.7.5 of 3GPP TS 24.229 [2] for the incoming INVITE request and all future 
requests and responses in the same dialog. 

4.5.4.3.1 CC possible indication 

4.5.4.3.1 .1 Normal operation 

When on a incoming communication the terminating AS supports the CCNR service, then the terminating AS shall 
insert a Call-Info header field with a purpose-parameter set to 'call-completion' and a m-parameter set to 'NR' in the 1 80 
(Ringing) response forwarded by the AS to indicate whether CCNR is possible or not, in accordance with draft-ietf- 
bliss-call-completion [5]. 

When on a incoming communication the callee is found to be busy and the terminating AS supports the CCBS service, 
then the terminating AS shall insert a Call-Info header field with a "purpose" header field parameter set to "call- 
completion" and a "m" header field parameter set to "BS" in the 486 (Busy Here) response generated by the terminating 
AS (in case of 'network determined user busy') or forwarded by the terminating AS (in case of 'user determined user 
busy') to indicate whether CCBS is possible or not, in accordance with draft-ietf-bliss-call-completion [5]. 

If the terminating AS knows that the CC is not possible on destination B, the terminating AS shall not include a Call- 
Info header field with a "purpose" header field parameter set to "call-completion" in any response sent to the originating 
side. 

4.5.4.3.1 .2 Exceptional procedures 
Not applicable 

4.5.4.3.2 CC Invocation 

4.5.4.3.2.1 Normal operation 

Several CC requests can be queued against one destination B in the destination B CC queue (queue B). The exact size 
of queue B (from 1 to 5 entries) is a destination network operator option. 

As a network option the destination network operator can reduce the sizes of the CC queues associated with individual 
users. The reduced size can be zero. The size of the CCBS queue can also be related to the size of the CCNR queue if 
existing. 

On receipt of a CC invocation request the terminating AS shall: 

a) check if the URI in the To header field of the SUBSCRIBE request is available for the requested CC service, and 
if it is available store the information received in the CC invocation request in the destination B queue and send a 
NOTIFY request to the originating AS according to draft-ietf-bliss-call-completion [5]. The terminating AS shall 
populate the NOTIFY request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request; 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a body set to a cc-state parameter set to 'queued'; and 

- if the retain option is supported at the terminating AS, a cc-service-retention parameter in the same body; 

b) start the service duration timer CC-T7; and 

c) monitor destination B 
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- in case of CCBS for becoming not busy; or 

- in case of CCNR for becoming not busy after having initiated an activity. 

Editor's note: Do methods for monitoring the callee for becoming not busy have to be described and included in an 
Annex C? 

4.5.4.3.2.2 Exceptional procedures 

When the invocation of the requested CC service is rejected by the terminating AS, in accordance with draft-ietf-bliss- 
call-completion [5] the terminating AS shall send a 480 (Temporarily Unavailable) response (short term denial) or a 403 
(Forbidden) response (long term denial), in the following cases: 

- if there are already the maximum number of requests queued against destination B ; 

if there is an interaction with other services which prevents the invocation of the requested CC service; 

- if the URI in the To header field of the SUBSCRIBE request is not available for the requested CC service at 
destination B. 

If the callee is no longer busy when the CCBS invocation request arrives or if the callee has answered the 
communication when the CCNR invocation request arrives, the terminating AS shall apply the normal procedures as 
described in subclause 4.5.4.3.3.1. 

NOTE: A general error, e. g. a syntax error, or a non-compliance to the call-completion event-package, is 
answered according to the procedures described in RFC 3265 [6]. 

4.5.4.3.3 CC Revocation 

4.5.4.3.3.1 Normal operation 

On receipt of a CC revocation request the terminating AS shall delete the CC request from the destination B queue. 

4.5.4.3.3.2 Exceptional procedures 

The terminating AS shall automatically revoke a particular request for the CC service if the CC service duration 
timer CC-T7 expires. If timer CC-T7 expires, the terminating AS shall send a NOTIFY request to the originating AS 
according to RFC 3265 [6] and draft-ietf-bliss-call-completion [5]. The terminating AS shall populate the NOTIFY 
request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the SUBSCRIBE 
request; 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a Subscription-State header field set to "terminated" and 

- the "reason" Subscription-State header field parameter set to 'rejected'. 

Editor's note: Is there a need to inform the originating AS about the cancellation reason (service duration timer)? 

4.5.4.3.4 CC Operation 

4.5.4.3.4.1 Normal operation 

4.5.4.3.4.1 .1 The callee becomes available 

When the callee becomes not busy, then the terminating AS shall check queue B for CCBS entries: 

- if there is an entry in the CCBS queue currently being processed, the terminating AS shall take no further action; 
or 
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- otherwise, the terminating AS shall examine the entries in the CCBS queue: 

- if an entry is suspended, the terminating AS shall take another entry; and 

- if an entry is not suspended, the terminating AS shall select it for the CCBS recall. 

NOTE: The algorithm for the order addressing entries in the queue is outside the scope of this document. It need 
not be order of creation of the queue entry. 

When the callee becomes not busy after having initiated an activity, then the terminating AS shall check queue B for 
CCNR entries: 

- if there is an entry in the CCNR queue currently being processed, the AS shall take no further action; 
otherwise, the AS shall examine the entries in the CCNR queue; 

- if an entry is suspended, the AS shall take another entry; 

- if an entry is not suspended, the terminating AS shall select it for the CCNR recall; 

NOTE: The algorithm for the order addressing entries in the queue is outside the scope of this document. It need 
not be order of creation of the queue entry. 

The terminating AS shall start the destination B idle guard timer CC-T8. When the destination B idle guard timer CC- 
T8 expires, the terminating AS shall process the selected CC request. 

4.5.4.3.4.1 .2 The CC recall is started 

When processing a CC request, provided that the callee is still available, the terminating AS shall start the CC recall 
procedure. 

The CC recall procedure is defined as follows: 

- the terminating AS shall send a NOTIFY request to the originating AS according to draft-ietf-bliss-call- 
completion [5]. The terminating AS shall populate the NOTIFY request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request 

- a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a body set to a cc-state parameter set to 'ready'; and 

- the terminating AS shall start the CC recall timer CC-T9. 

4.5.4.3.4.1 .3 Incoming communication during the recall processing 

If the terminating AS receives an INVITE request while a CC recall is processed, the terminating AS shall check 
whether this new incoming communication includes a CC call indicator (a "m" SIP URI parameter is added to the 
Request-URI). 

If the INVITE request includes a CC call indicator, the terminating AS shall offer the CC call to the callee. 

If the INVITE request does not include a CC call indicator, the terminating AS shall compare the service requirements 
and destination selection information with the information stored in the destination B queue for the CC request which is 
currently being processed: 

- if the two sets of information are identical, the terminating AS shall offer the incoming communication to the 
callee; or 

otherwise the terminating AS shall reject the incoming communication. 
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4.5.4.3.4.1 .4 Procedures after the recall was offered to the callee 

When the terminating AS has sent a 183 (Session Progress) response, a 180 (Ringing) response or a 200 (OK) response, 
it shall: 

- stop the timers CC-T7 and CC-T9; 

- delete the CC request from the destination B queue 

- send a CC revocation notification as described in subclause 4.5.4.3.3.2 to the originating AS; and 

- check whether the callee is busy: 

- if the callee is busy, the terminating AS shall take no further action; or 

- if the callee is not busy, the terminating AS shall service the queue for destination B as described above. 

4.5.4.3.4.1 .5 Further procedures 

When a CC request becomes not suspended because user A has become free (i.e. not busy and not CC busy), then, if the 
callee is available and there is no entry in the CC queue which is currently being processed, the terminating AS shall 
service the destination B queue as described above. 

If the processing of a CC request results in suspending that CC request, the terminating AS shall stop timer CC-T9 and 
attempt to process another CC request in the same queue. 

If the processing of a CC request results in deactivating that CC request, the terminating AS shall stop timers CC-T7 
and CC-T9 and attempt to process another CC request in the same queue. 

4.5.4.3.4.2 Exceptional procedures 

a) The callee is busy when destination B idle guard timer expires: 

If, upon expiry of the destination B idle guard timer CC-T8, the callee is busy (e.g. the callee has initiated an 
outgoing communication), then the terminating AS shall defer servicing of the destination B CC queue until the 
callee becomes not busy again. 

b) The terminating AS receives a "ready" notification while processing the destination B CC queue: 

See subclause 4.6.10. 

c) The callee is busy upon arrival of the CC call: 

If the callee is again busy when a CC call arrives, then the procedures depend on whether the retention option is 
supported across the networks: 

- if the retain option is not supported at the terminating AS, the terminating AS shall cancel the corresponding 
CCBS request; the terminating AS shall send a 486 (Busy Here) response with an Call-Info header field with 
a "purpose" header field parameter set to "call-completion" to the originating AS; if a new CCBS invocation 
request is received from the originating AS, normal procedures apply, according to subclause 4.5.4.3.2; 

- if the retain option is supported at the terminating AS, the terminating AS shall retain the original CCBS 
request in the queue; in this case the terminating AS shall continue to monitor destination B, shall not restart 
the timer CCBS-T7, shall stop timer CC-T9 and shall send a 486 (Busy Here) response with an Call-Info 
header field with a "purpose" header field parameter set to "call-completion" to the originating AS. 

d) No CC call as result: 

If no CC call results from the CC recall mechanism, the recall timer CC-T9 expires. In this case the terminating 
AS shall send a NOTIFY request to the originating AS according to RFC 3265 [6] and draft-ietf-bliss-call- 
completion [5]. The terminating AS shall populate the NOTIFY request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request; 

- a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 
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- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a Subscription-State header field set to 'terminated' and 

- the "reason" Subscription-State header field parameter set to 'rejected', 

Editor's note: Is there a need to inform the originating AS about the cancellation reason (recall timer)? 

4.5.4.4 Actions at the ternninating UE 

Basic call procedures according to 3GPP TS 24.229 [2] shall apply. 

4.6 Interaction of Call-Completion with other services 

4.6.1 Communication waiting (CW) 

The CW AS shall not invoke the CW service on a CC recall. 

NOTE 1 : For a waiting communication, destination B is not considered as busy. 

If the communication waiting indication cannot be given at the destination B, user A will receive busy 
indication and can invoke the CCBS service to destination B. 

NOTE 2: Procedures for the case the CC call encounters busy again are described in subclause 4.5.4.3.4.2. 

4.6.2 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

NOTE: When receiving a CC recall indication, user A can invoke the communication hold service in order to 
make interface resources available for the establishment of the CC call. 

4.6.3 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.4 Terminating Identification Restriction (TIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.5 Originating identification presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.6 Originating identification restriction (OIR) 

The OIR AS shall enforce the privacy settings of the originating call on the CC call. 

The OIR AS shall enforce the privacy settings of the originating call for SUBSCRIBE and NOTIFY requests when CC 
is invoked. 

4.6.7 Conference calling (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 
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4.6.8 Communication diversion services (CDIV) 

4.6.8.1 General 

The CDIV AS shall not divert a CC recall. The CDIV AS shall give a CC recall to user A at user A's original location. 

4.6.8.2 Communication Forwarding Unconditional 

For CFU activated by B before A requests CC on B : 

- If user B has activated CFU, and the forwarded communication results in a call-completion condition at user C, 
the CC AS shall inform user A that CC is possible at user C. If user A activates CC and subsequently activates 
CFU, the CDIV AS shall give the CC recall to user A at his original location. 

As a network option, in case of a diversion at user B, the CC AS shall not inform user A that CC is possible. 

For CFU activated by B after A requests CC on B : 

- If user B activates CFU after user A has activated CC on user B, then the CC AS shall cancel the CC request and 
shall send a notification "CC cancelled" to the user A. 

As a network option, the CC AS shall suspend the CC request until user B deactivates CFU. If the service 
duration timer CC-T3 expires before user B deactivates CFU, the CC AS shall cancel the CC request. 

NOTE: How the "CC cancelled" notification is send to user A is FFS. 

4.6.8.3 Communication forwarding busy 

For CFB activated by B before A requests CC: 

- If user B has activated CFB and is busy, and the forwarded communication results in a call-completion condition 
at user C, the CC AS shall inform user A that CC is possible at user C. 

As a network option, the CC AS shall inform user A that CCBS at user B is possible. 

For CFB activated by B after A requests CC on B : 

- If user B activates CFB after user A has activated CC on user B, a CC call from user A which encounters a busy 
condition at user B shall be treated as follows: 

- user B shall be considered as being busy and the CC AS shall apply the procedures of CCBS; or 
the CDIV AS shall forward the communication as a normal communication. 

4.6.8.4 Communication forwarding no reply 

For CFNR activated by B before A requests CC: 

If user B has activated CFNR and does not answer the communication, and the forwarded communication results 
in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C. 
As a network option, the CC AS shall inform user A that CCNR at user B is possible. 

For CFNR activated by B after A requests CC on B : 

- If user B activates CFNR after user A has activated CC on user B, a CC call from user A which encounters a no 
reply condition at user B shall be treated as follows: 

- the CC AS shall apply the procedures of CCNR; or 

the CDIV AS shall forward the communication as a normal communication. 

4.6.8.5 Communication forwarding not registered 

For CFNL activated by B before A requests CC on B: 
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- If user B has activated CFNL and is not logged in, and the forwarded communication results in a call-completion 
condition at user C, the CC AS shall inform user A that CC is possible at user C. 

As a network option, the CC AS shall inform user A that CCNR at user B is possible. 

For CFNL activated by B after A requests CC on B : 

If user B activates CFNL after user A has activated CC on user B, then the CC AS shall cancel the CC request 
and shall send a notification "CCBS cancelled" to the user A. 

As a network option, the CC AS shall suspend the CC request until user B deactivates CFNL. If the service 
duration timer CC-T3 expires before user B deactivates CFNL, the CC AS shall cancel the CC request. 

NOTE: How the "CC cancelled" notification is send to user A is FFS. 

4.6.8.6 Communication deflection (CD) 

For the originating user A: 

- If a communication to the called user B is deflected to user C by the CD service and results in a call-completion 
condition at user C, the CC AS shall inform user A that CC is possible at user C. The CDIV AS shall not deflect 
a CC recall. 

For the called user B : 

- The CDIV AS shall not deflect a CC call. 

4.6.9 Advice of charge (AOC) 

Charging information can be given for the original communication, and for the resulting CCBS communication. 

4.6.1 Completion of communications (CCBS/CCNR) 

A user can be both a "user A" and a "user B" simultaneously, i.e. that user can have activated the CC service and have 
CC requests outstanding whilst at the same time that user can be the destination of CC requests from other users. 

The CC AS shall handle CC requests activated by this user (the user' s queue A) with priority over CC requests 
activated by other users on this user (the user's queue B), see subclause 4.5.4.3.4.1.1. 

4.6.1 1 Malicious communication identification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.12 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.13 Message Waiting Indication (MWI) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.14 Explicit Communication Transfer (ECT) 

Editor's note: For further studies. For ECT with REFER the transferee does not know to who he sends the INVITE, 
and if the SUBSCRIBE is sent on another dialog , the SUBSCRIBE may not reach the target AS. 

4.6.15 Flexible Alerting (FA) 

No impact, i.e. neither service shall affect the operation of the other service. 
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4.6.16 Customized Alerting Tones (CAT) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8 Parameter values (timers) 



4.8.1 

CC-Tl 

CC-T2 
CC-T3 



Timers referring to the originating AS 



NOTE: 



CC-T4 



CCNR-T5 



Retention timer. This timer specifies the amount of time that the network retains the communication 
information of the original communication which was not established successfully. After being informed 
that CC is possible the caller sends a CC invocation request before expiry of this timer. The minimum 
value of this timer is 15 seconds. 

CC request operation timer. Supervision of response to a CC activation request sent from the originating 
AS to the terminating AS. CC-T2 will expire if signalling is not possible, at signalling failures, or if the 
terminating AS cannot respond. The minimum value of this timer is 10 seconds 

CC service duration timer. This timer specifies the maximum time the service will remain activated for 
user A. The maximum value of this timer is 180 minutes. 

The value of the CC service duration timer can differ in the network dependent on its usage for CCBS or 
CCNR. 

CC recall timer. This timer specifies the maximum time the originating AS will wait for a response from 
user A to a CC recall. The maximum value of this timer is 20 seconds. 

No-reply timer. This timer specifies the maximum time after which the originating AS will provide the 
announcement that CCNR is possible, and inband activation is possible. The maximum value of this timer 
is 20 seconds. 



4.8.2 

CC-T7 

NOTE: 
CC-T8 

CC-T9 



Timers referring to the terminating AS 



CC service duration timer CC-T7 expiry will only be meaningful if the expiry of CC-T3 has not been 
notified to the terminating AS. CC-T7 takes a longer duration than CC-T3, i.e. CC-T7 expires at 
abnormal situations only. The maximum value of this timer is 190 minutes. When CC-T7 expires, the CC 
request will be cancelled at the terminating AS as well as at the originating AS. 

The value of the CC service duration timer can differ in the network dependent on its usage for CCBS or 
CCNR. 

Destination B idle guard timer. This timer specifies the amount of time the terminating AS will delay 
after destination B has become free, before initiating a CC recall towards the originating AS. The 
maximum value of this timer is 10 seconds. 

Recall timer. CC-T9 should expire at emergency only, i.e. the recall should be cancelled by CC-T4 at the 
originating AS if recall is not responded to. Duration of CC-T9 = 20 seconds + some seconds for CC call 
set-up. The maximum value is 30 seconds. 
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Annex A (informative): 
Signalling flows 

A.1 CCBS activation and CCBS call 
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UE-A 



Intermediate IM CN 
subsystem entities 
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Call-Info: <T-AS>; 
purpose=call-completion; 
m=BS ; 



8. 486 Busy 



h9. 183 Session progress 



IVR: CCBS possible and activation 
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From:<UE-A> 
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Event:call-completion 
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cc-service-retention] 



16. NOTIFY 
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5. INVITE 
6. 486 Busy 



busy state supervision 
begins 



user B becomes 
available 



27. INVITE sip:UE-B 



Figure A.1.1: CCBS activation and CCBS call 

Figure A.1.1 shows a basic signalling flow for a CCBS activation and a CCBS call. 
Call flows 
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Editor's note: The following explanations are a first draft, more details will be added along with the ongoing 
specification of the CCBS internet draft. 

I to 5: The communication is initiated by UE-A by sending an INVITE request. The Request-URI will include the 

URI of UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the originating AS and after 
that to the terminating AS and further on to UE-B. 

6: UE-B answers with a 486 (Busy Here) response. The 486 (Busy Here) response is routed back to the terminating 
AS. 

7 to 8: The terminating AS inserts a Call-Info header field in the 486 (Busy Here) response according to the 

procedures described in draft-ietf-bliss-call-completion [5]. The Call-Info header field will contain the URI of 
the terminating AS with an "m" header field parameter set to "BS" (busy subscriber). It further includes a 
"purpose" header field parameters set to "call-completion". The 486 (Busy Here) response is routed back to the 
originating AS. 

9 to 10: The originating AS sends back a 183 (Session Progress) response to UE-A and initiates IVR procedures. 
User A is informed that CCBS is possible. User A activates CCBS. 

I I to 14: The originating AS subscribes for the call-completion event package according to the procedures 
described in draft-ietf-bliss-call-completion [5] at the terminating AS. The originating AS generates a 
SUBSCRIBE request which Request-URI will include the URI of the terminating AS. In order to mark the 
SUBSCRIBE request as a request for CCBS, the originating AS adds the "m" SIP URI parameter with the value 
"BS" to the Request-URI. The From header field will include the caller URI. The To header field will include the 
callee URI. 

The terminating AS accepts the subscription and starts busy state supervision procedures on the callee. 

15 to 18: The terminating AS sends a notification to the originating AS, according to the procedures described in 
draft-ietf -bliss-call-completion [5]. The Request-URI of the NOTIFY request will include the URI of the 
originating AS. The body contains parameters informing of the caller's call-completion state 'queued' and the 
availability of the call-completion service retention at the terminating AS. After confirmation of the notification 
the originating AS starts announcements procedures informing about the activation of CCBS. 

19 to 20: The originating AS forwards the 486 (Busy Here) response to UE-A. 

21 to 24: The terminating AS sends a NOTIFY request to the originating AS, according to the procedures described 
in draft-ietf-bliss-call-completion [5]. The body contains a parameter informing of the caller's call-completion 
state 'ready' (for recall). The originating AS confirms the notification and initiates the CCBS recall to UE A 
(implementation options: sending a REFER request or starting Spec procedures; in either case, the "m" SIP URI 
parameter set to "BS" will be included in the Request-URI of the REFER request or the INVITE request, 
respectively). 

25 to 26: The originating AS starts the CCBS call by sending an INVITE request to UE-B. In order to mark the 
INVITE request as a prioritized request for call-completion, the originating AS adds the "m" SIP URI parameter 
with the value 'BS' to the Request-URI. 
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A.2 CCBS suspend and resume procedures 



UE-A 



Intermediate IM CN 
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9. PUBLISH sip:T-AS URI 
From:<caller-URI> 
To:<caller-URI> 
iCall-lnfo: <T-AS URI>; - 
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Figure A.2.1 : CCBS suspend and resume procedures 

Figure A.2.1 shows a basic signalling flow for CCBS suspend and resume procedures. 

Editor's note: The usage of PUBLISH for suspend and resume procedures is still discussed at the IETF. 

Call flows 

Editor's note: The following explanations are a first draft, more details will be added along with the ongoing 
specification of the CCBS internet draft. 



ETSI 



3GPP TS 24.642 version 8.0.1 Release 8 28 ETSI TS 124 642 V8.0.1 (2009-01) 

1 to 4: UE-A is busy and the CCBS recall fails. The originating AS initiates the suspension procedure. It generates a 
PUBLISH request according to the procedures described in draft-ietf-bliss-call-completion [5]. The Request-URI 
of the PUBLISH request includes the URI of the terminating AS. The From header field and the To header field 
include the caller URI. The body of the PUBLISH request indicates the PIDF state 'closed'. 

5 to 8: The terminating AS suspends the queue entry and sends a NOTIFY request to the originating AS, according 
to the procedures described in draft-ietf-bliss-call-completion [5]. The body contains a parameter informing of 
the caller's call-completion state 'queued'. The originating AS starts busy state supervision procedures on UE-A. 

9 to 12: UE-A becomes not busy. The originating AS initiates the resumption procedure. It generates a PUBLISH 
request according to the procedures described in draft-ietf-bliss-call-completion [5]. The Request-URI of the 
PUBLISH request includes the URI of the terminating AS. The From header field and the To header field 
include the caller URI. The body of the PUBLISH request indicates the PIDF state 'open'. 

13 to 16: The terminating AS resumes the queue entry and sends a NOTIFY request to the originating AS, 
according to the procedures described in draft-ietf-bliss-call-completion [5]. The body contains a parameter 
informing of the caller's call-completion state 'queued'. 
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A.3 CCNR activation 
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purpose=call-completion; 
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Figure A.1.3: CCNR activation 

Figure A.1.3 shows a basic signalling flow for a CCNR activation. 



ETSI 



3GPP TS 24.642 version 8.0.1 Release 8 



30 



ETSI TS 124 642 V8.0.1 (2009-01) 



Call flows 

Editor's note: The following explanations are a first draft, more details will be added along with the ongoing 
specification of the CC internet draft. 

I to 5: The communication is initiated by UE-A by sending an INVITE request. The Request-URI will include the 

URI of UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the originating AS and after 
that to the terminating AS and further on to UE-B. 

6: UE-B answers with a 180 (Ringing) response. The 180 (Ringing) response is routed back to the terminating AS. 

7 to 8: The terminating AS inserts a Call-Info header field in the 180 (Ringing) response according to the procedures 
described in draft-ietf -bliss-call-completion [5]. The Call-Info header field will contain the URI of the 
terminating AS with a "m" header field parameter set to "NR" (no reply). It further includes a "purpose" header 
field parameter set to "call-completion". The 180 (Ringing) response is routed back to the originating AS. 

9 to 10: The originating AS removes the Call-Info header field, forwards the 180 (Ringing) response to UE-A and 
initiates IVR procedures. User A is informed that CCNR is possible. User A activates CCNR. 

I I to 14: The originating AS subscribes for the call-completion event package according to the procedures 
described in draft-ietf-bliss-call-completion [5] at the terminating AS. The originating AS generates a 
SUBSCRIBE request which Request-URI will include the URI of the terminating AS. In order to mark the 
SUBSCRIBE request as a request for CCNR, the originating AS adds the "m" SIP URI parameter with the value 
"NR" to the Request-URI. The From header field will include the caller URI. The To header field will include 
the callee URI. 

The terminating AS accepts the subscription and starts supervision procedures on activity of the the callee. 

15 to 18: The terminating AS sends a notification to the originating AS, according to the procedures described in 
draft-ietf -bliss-call-completion [5]. The Request-URI of the NOTIFY request will include the URI of the 
originating AS. The body contains parameters informing of the caller's call-completion state 'queued' and the 
availability of the call-completion service retention at the terminating AS. After confirmation of the notification 
the originating AS starts announcements procedures informing about the activation of CCBS. 

19 to 28: UE-A initiates the termination of the session setup by sending a CANCEL request to UE-B. 

29 to 38: UE-B terminates the session setup by sending a 487 Request terminated to UE-A. 

A.4 CCNR call 
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Event:call-completion 
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7. INVITE sip:UE-[ 



Figure A.1.4: CCNR call 
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Figure A. 1.4 shows a basic signalling flow for a CCNR activation and a CCNR call. 

Call flows 

Editor's note: The following explanations are a first draft, more details will be added along with the ongoing 
specification of the CCBS internet draft. 

1 to 4: The terminating AS sends a NOTIFY request to the originating AS, according to the procedures described in 
draft-ietf-bliss-call-completion [5]. The body contains a parameter informing of the caller's call-completion state 
'ready' (for recall). The originating AS confirms the notification and initiates the CCNR recall to UE A 
(implementation options: sending a REFER request or starting Spec procedures; in either case, the "m" SIP URI 
parameter set to "NR" will be included in the Request-URI of the REFER request or the INVITE request, 
respectively). 

5 to 6: The originating AS starts the CCNR call by sending an INVITE request to UE-B. In order to mark the 

INVITE request as a prioritized request for call-completion, the originating AS adds the "m" SIP URI parameter 
with the value "NR" to the Request-URI. 

7: The terminating AS removes the "m" SIP URI parameter and forwards the INVITE request to UE-B. 
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Annex B (informative): 
Example of filter criteria 



This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 

An example of an IFC when the CCBS or CCNR services are active at the originating S-CSCF is: 

- Method: INVITE. 

Editor's note: It's needed to consider if further clarification is needed for Filter Criteria in cases where additional 
services based upon INVITE are also deployed. 
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